Flatten migrations #1187
Flatten migrations #1187
Conversation
server/migrations/utils/index.js
Outdated
There was a problem hiding this comment.
This reorganization is welcome! I am going to assume no functional changes. Let me know if this assumption is incorrect.
There was a problem hiding this comment.
I am going to assume no functional changes
That's right!
| const dumpTable = async tableName => { | ||
| try { | ||
| const dumpFilePath = path.resolve( | ||
| `${__dirname}/../dumps/dumpTable_${tableName}_${new Date().getTime()}.sql` |
There was a problem hiding this comment.
These files may eventually crowd directories on our local machines. It is easy enough to delete but just pointing this out. I don't think there is an action item here unless you want to add something to purge especially old ones.
There was a problem hiding this comment.
I think I'd rather this be left to each contributor to decide how to handle for themselves since they're gitignored. I suppose utils for clean:migrationDump:tables or clean:migrationDump:databases could be added but I don't think it's super necessary (to me)
There was a problem hiding this comment.
Makes sense! No need for a util for now.
| await exec( | ||
| `pg_dump -t '"${tableName}"' ${process.env.PGDATABASE} --inserts > ${dumpFilePath}` | ||
| ); | ||
| } catch (err) { |
There was a problem hiding this comment.
Do we want to catch this? Might be safer to not run the migration if making the dump fails.
There was a problem hiding this comment.
Good point! Addressed in 72861c2
The migrations used in this project have grown as much as "deemed necessary" over the project's lifespan. This PR aims to remove those migrations and preserve the structure of the tables. Due to the suggested point for this PR's merge, there shouldn't be a need to preserve any functional changes of those previous migrations as all environments should be up to date migration-wise and the migrations were mostly focused on keeping up to date with changes to the application's code (from what I've gone through at least).
This should present a fresh start on the migrations by limiting the time taken to run them and also attempt to maintain the practice of, as best as possible to avoid using application code in any migration going forward.